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Abstract 

Software development organizations , both commercial and governmental, are 
undergoing rapid change spurred by developments in the computing industry. To 
stay competitive, these organizations must adopt new technologies, skills, and prac- 
tices quickly. Yet even for an organization with a well-developed set of software 
engineering models and processes, transitioning to a new technology can be 
expensive and risky. Current industry trends are leading away from traditional 
mainframe environments and toward the workstation-based, open systems world. 
This paper presents the experiences of software engineers on three recent projects 
that pioneered open systems development for the National Aeronautics and Space 
Administration 's (NASA ’s) Flight Dynamics Division of the Goddard Space Flight 
Center (GSFC). 


Introduction 

How can an organization effectively accomplish 
technology transition ? Introducing a new tech- 
nology into an organization requires an invest- 
ment. But what is the nature and size of that 
investment, and how long will it be before bene- 
fits are realized? How can one quantitatively 
define these benefits and measure the results? 
Whatever the ultimate reward of the technology', 
transition is a step into uncharted waters. Tech- 
nology infusion requires managers to rethink the 
way they approach the ordinary project man- 
agement challenges of developing effort esti- 
mates, achieving planned productivity', and 
dealing with evolving requirements. 

The authors of this paper develop software sys- 
tems under contract to the NASA/GSFC Flight 
Dynamics Division (FDD). For more than two 
decades, the FDD has successfully fielded soft- 
ware systems to support NASA spacecraft 


missions in a relatively stable mainframe/- 
minicomputer environment. This stability has 
allowed the FDD to optimize its software 
development process. During the first half of the 
1990s, the authors worked on three projects in 
the forefront of the FDD's transition from its 
legacy environment to a workstation-based open 
systems environment. We discovered that our 
established development process had to transition 
as well, in unanticipated ways. Our experiences 
in this transition and our lessons learned are 
recorded here with some recommendations for 
managing technology transitions 

A model commonly used for technology' transfer 
conceives of technology as moving from a pro- 
ducer to a consumer organization. The transition 
moves through the phases of early experimenta- 
tion and exploration to technical maturity. The 
projects discussed in this paper fall primarily 
within the exploratory phase, where work has 
progressed from initial experiments to full-scale 
development, but the technology is still used by a 
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minority of the organization’s staff. Marvin 
Zelkowitz defined these phases in a paper pre- 
sented at the 18th Annual Software Engineering 
Workshop, ‘Software Engineering Technology 
Transfer: Understanding the Process.” 

This paper provides information on the software 
development organization, then summarizes our 
observations on each of the case study projects. 
We then organize the lessons learned and rec- 
ommend elements of a technology transition plan 
and ways in which new technology projects 
might be better managed. 


The FDD Software 
Developm ent Organization 

The FDD entered the transition with a mature 
software development organization that included 
the Software Engineering Laboratory (SEL), a 
research and process improvement group whose 
mature measurement program, cost and schedule 
estimation models, and management guidelines 
support software development and technology 
transfer in this environment. 

The FDD had patterned its success on a basic 
scientific method of gradual, continuous improve- 


ment in software engineering technology in a 
stable computing environment. Controlled inno- 
vations were introduced to test new techniques 
and tools. Studies usually were conducted 
through pilot projects that applied the new tech- 
nology under strict controls, with the results 
evaluated against the organization s norms. The 
FDD would then incorporate proven beneficial 
technologies into the standard technology' suite. 

The FDD had made little investment in explor- 
ing open systems technologies. The FDD’s few 
projects outside the mainframe environment were 
considered out of the organization’s mainstream 
Developers collected few statistics, and few 
software engineering experiments were con- 
ducted on these projects. When the computing 
industry began to shift toward workstations, the 
C language, and open systems concepts, the 
FDD had little background in these technologies. 

Since 1990, the FDD has been moving toward 
workstation computing platforms and open sys- 
tems technology, driven primarily by factors 
external to the development organization. They 
have done so without the benefit or lead of SEL 
experiments. Figure 1 illustrates the FDD’s 



Figure 1. FDD Transition to Open Systems 
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investment in new technology exploration and the 
quickening pace of the transition. The case 
studies discussed in this report are shown at the 
bottom of the figure in their chronological 
context. 


The Case Study Projects 

Table 1 provides an overview of the three case 
study projects, listing the size and language, 
operational computing environments, and devel- 
opment tools. The projects were planned by 
tailoring the domain-specific FDD cost and 
schedule models. The tailoring allowed for some 
training on specific new technologies. As work 
progressed, plans were revised to reflect the 
technology issues. Figure 2 summarizes the 
development results compared to the plan. 


Case Study 1 : User Interface 
Executive (UIX) 

The FDD saw a need for a common framework 
in the new environment. The FDD planned the 
UIX as a common user interface and executive 
framework for distributed mission support sys- 
tems. The decision to base the user interface on 
X/Motif was primarily driven by industry trends. 
The aim was to create a configurable system to 
be used by developers working in Ada, C, or 
FORTRAN to build application programs that 
shared a common set of interactive tools. The 
application developers would not be required to 
code in X/Motif or to use a GUI builder. The 
UIX would allow application users to control 
multiple, distributed processes in a platform- 
transparent manner. Finally, the FDD required 
that the UIX support existing hardware 


Table 1. Case Study Project Characteristics 


Project 

Descriptors 

Case Study 1: UIX 

Case Study 2: GSS 

Case Study 3: XTE AGSS 

Size in KSLOCs 
and Language 

65,000 C 

212,000 Ada 

66.000 C 

58.000 FORTRAN 

9.000 User Interface Language 

(UIL) 

Platform and 
Infrastructure 
Software 

♦ 386 and 486 PCs 

♦ Santa Cruz Operation (SCO) 
UNIX 

♦ HP 9000/7xx series 
workstations 

♦ HP/UX 

♦ External Data Representation 
(XDR) 

♦ X/Motif (X11R4, later R5) 

♦ Digital Equipment Corp. 
(DEC) VAX 8820 (later Alpha 
AXP/4000), open VMS 

♦ 486 PCs 

♦ SCO UNIX 

♦ HP 9000/7xx series 
workstations 

♦ HP/ UX 9.0.3 or higher 

♦ Hewlett-Packard (HP) 7xx 
workstations 

♦ HP/UX 

♦ X-terminal and VT2000 
emulation 

♦ X/Motif (X11R5) 

Development 

Tools 

♦ Intersolv PVCS version 
control 

♦ SCO Open Desktop toolset 

♦ DEC Configuration Manage- 
ment System (CMS) 

♦ DEC VAXSet Development 
Toolset 

♦ DEC Ada Compiler Version 
2.2 

♦ Rational Software Corp. 
VADSelf Ada for 486 SCO, 
HP/UX 

♦ Builder Xcessory (X Window 
GUI builder) 

♦ HP full-screen editor 

♦ HP desktop environment 
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Size 


Schedule 



planned 


actual 


Compare to size growth in 20% to 40% range and schedule growth in 5% to 35% range 
on recent maintenance and VAX development projects 


Figure 2. Planned Versus Actual Size and Schedule 


(the IBM mainframes and Intel-386 PCs) to the 
maximum extent possible. 

Prototyping played a critical role. The ambi- 
tious goals of the UIX project were all the more 
challenging because it was the first to use open 
systems technology within the FDD. To learn 
the technology and refine the requirements, the 
development team built a prototype that covered 
all major facets of the proposed UIX. Develop- 
ment and evaluation of the prototype ultimately 
spanned a year and a half. In parallel with the 
prototype evaluation, the team began specifying 
the content of the actual UIX. The prototyping 
experience led to architectural and conceptual 
changes in the specified product, including aban- 
doning the goal of supporting the IBM main- 
frame as an application host and deferring 
implementation of distributed process control 
until industry capabilities had further evolved. 

Lack of a technical infrastructure and an 
organizational transition plan caused difficul- 
ties. Without a preestablished infrastructure 


finiddleware”such as a network file server), the 
traditional separation of concerns between the 
systems support and software development 
organizations was blurred. It was sometimes 
unclear whether responsibility for selecting an 
infrastructure product lay with the project that 
first needed the capability (in this case, the UIX) 
or with the support organization that maintained 
the FDD’s institutional hardware resources 
Although cross-organizational groups addressed 
these issues, the lack of an overall transition plan 
led to misunderstandings and organizational 
friction. 

The FDD 's traditional functional requirements 
and specifications methodology was not 
sufficient for establishing the infrastructure. 
Software developers, especially those from 
mainframe backgrounds, tend to take the exis- 
tence of a computing system architecture for 
granted, but this was not the case with the UIX. 
The developers attempted to define the required 
software infrastructure using data flow diagrams 
and functional specifications, the method with 
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which they were familiar. Unfortunately, their 
limited knowledge of the technologies involved 
and the immaturity of available products mud- 
died the development effort. One round of proto- 
typing followed by one round of specification 
development was not sufficient, nor was the 
specification formalism conducive to iterative 
refinement. 

Prototyping experience led to technical learning 
but not better planning. Although the prototyp- 
ing experience clarified technical issues, it taught 
the developers little about planning the develop- 
ment project. They believed that the effort saved 
by rapid prototyping would offset the additional 
effort needed to come up the learning curve on 
the new technologies. In the actual project 
experience, there was still a substantial learning 
curve in spite of an overlap of development team 
members with the prototyping team. (For 
example, the complexity of X/Motif coding was 
underestimated.) The prototyping team achieved 
the organization's average productivity' based on 
historical data. However, productivity on the 
actual ULX development was initially only half 
that of the prototype project, as the team faced 
continued technical learning as well as the 
documentation and inspection demands of a dis- 
ciplined development methodology. Further- 
more, the final system w r as larger (by a factor of 
about two) and more complex than indicated by 
the prototyping. 

Case Study 2: Generalized 
Support Software (GSS) 

The GSS project transitioned the post- 
integration development phase only. The GSS 
is a multiapplication flight dynamics support 
class library' designed to interface with the UIX. 
The GSS project was the FDD’s first Ada lan- 
guage software development project to make the 
transition to the open systems workstation envi- 
ronment. Unlike the other two case studies pre- 
sented in this paper, the GSS was not developed 
in an open systems environment. The GSS was 
designed, coded, and integrated in the standard 
development environment for Ada-based 


195 


software projects in the FDD, which was a DEC 
VAX system (later, a DEC Alpha system). The 
code was then ported to the SCO UNIX envi- 
ronment on PCs for integration with the UIX to 
create the operational system (an attitude 
telemetry simulator), with the UIX providing the 
user interface services. Thus, the technological 
"leap” taken by GSS was considerably smaller. 

The infrastructure needed for a workstation- 
based development was underestimated. When 
the GSS project started production in January 
1993, the FDD did not have sufficient worksta- 
tions and associated Ada development tools to 
support a development the size of the GSS on 
workstations. The GSS project was not budg- 
eted to procure the workstations and tools needed 
to develop the system totally in a workstation 
environment. FDD management decided that the 
most cost-effective approach would be to 
develop the GSS software on the institutional 
Ada development platform, a VAX 8820 mini- 
computer, until the build integration test phase. 
At that time, the software for the build would be 
ported to the workstation environment. 

A familiar development environment helped 
control system growth. The growth in size of 
the GSS is fairly consistent with FDD projects 
over the past 5 years. The reasons for the rela- 
tively limited growth compared to the other case 
studies are 

♦ GSS is developed in Ada, a language FDD 
software developers have been using for 
almost a decade. 

♦ The developers were familiar with the GSS 
development environment and toolset, and 
only the latter phases of the life cycle (build 
integration through independent test) were 
performed on the workstation platforms. 

The GSS project comprised pure computational 
applications software, not interactive software. 
The GSS project did not have to deal with user- 
system interface issues m the new open systems 
environment. Because the UIX system provides 
the GUI for GSS-based flight dynamics 
applications, the GSS project was “shielded” 
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from many of the technological hurdles and 
learning curve relating to building GUIs on 
workstation platforms. This experience suggests 
that scientific application development is less 
affected when moving to open systems platforms 
than is user interface software development. 

Case Study 3: X-Ray Timing 
Explorer Attitude Ground Support 
System (XTE AGSS) 

The FDD faced a new requirement to deliver 
software on workstations . On this project the 
FDD developed mission attitude ground support 
applications in an open systems workstation 
environment. The FDD had developed these 
types of applications before but only in an IBM 
mainframe environment. The FDD was required 
to deliver the applications to a separate GSFC 
organization, the Mission Operations Division 
(MOD), for integration into their operational 
system. Such applications had previously been 
installed and operated only within the FDD envi- 
ronment. The MOD systems use a locally devel- 
oped package called Transportable Payload 
Operations Control Center (TPOCC) to provide 
the client-server framework. 

Project planning was largely based on experi- 
ence in the legacy environment . The project 
planners estimated size (in lines of code) of the 
applications based on previous FDD systems. 
The planners determined they could reuse a large 
amount of FORTRAN computational code being 
developed concurrently on the mainframe. Since 
XTE AGSS was a first-of-a-kind project, the 
planners lacked good comparisons to help esti- 
mate how the use of TPOCC and X/Motif 
graphics would affect the size. A productivity 
rate 20 percent lower than the FDD norm was 
used to account for the new technology’ learning 
curve. 

The XTE development effort was significantly 
underestimated . As it turned out, the size of the 
applications was underestimated by a factor of 
three, primarily because 

♦ Planners underestimated the size of the 
TPOCC and graphics-related code. 


♦ Reused code was larger than expected. 

♦ Requirement changes added major new 
functionality. 

Productivity on the initial builds was considera- 
bly lower than expected. The main causes of the 
lowered productivity were underestimation of the 
complexity of the new technology’, the lack of 
X/Motif expertise on the team, and skill mix 
problems. Productivity increased in the later 
builds as the team became more experienced 
with the technology and as the skill mix 
improved; some builds met or exceeded the FDD 
norm. 

The traditional methodology had to change to 
incorporate iteration. Only about half the unit 
designs had been completed by the time of criti- 
cal design review. (FDD methodology called for 
all unit designs to be complete at that point.) 
This indicated trouble, but the developers and 
their management did not realize the full extent 
of the effort underestimation until the coding 
phase. Then it became clear that they could not 
complete the project according to the original 
plans, and they had to renegotiate the delivery 
schedule and add staff. The new schedule was 
still highly compressed because of XTE mission 
deadlines, forcing the developers into an iterative 
approach of designing and coding build by 
build. For the most part the iterative approach 
worked well, though it made assessing progress 
difficult. 

Requirements instability exacerbated problems. 
It is common in FDD development projects that 
software requirements evolve during the course 
of development. The XTE project encountered 
challenging, though not unprecedented, require- 
ments instability, partly because the FDD ana- 
lysts thought of ways to make the software more 
generic well after design and implementation 
were underway. System specifications were 
changed on several occasions to serve the best 
long-term interests of the FDD. The resulting 
perturbations were far more severe than they 
normally would have been because the project 
was in technology transition. 


SEW Proceedings 


196 


SEL-94-006 


The development team needed immersion in the 
technology to come up to speed. One of the 
major challenges of the project was learning the 
TPOCC system. This amounted to technology 
transfer from the MOD to the FDD. The 
TPOCC system is large and complicated, and the 
XTE development team could find no single per- 
son who was expert in all aspects of the system. 
Early in the implementation phase, part of the 
development team relocated to the MOD devel- 
opment facility for 2 months. The relocation 
was very useful for promoting communications, 
though interaction was limited because the MOD 
developers were busy with their own projects. 
The early builds implemented the TPOCC inter- 
faces and were kept relatively small to allow 
quick feedback. To get a testable framework in 
place, the team split the first build in two when it 
turned out to be far larger than planned. 

Unrecognized technological assumptions created 
transition problems. The bi gg est problem 
encountered with TPOCC was not in implement- 
ing the application interfaces, but in installing 
TPOCC in the FDD. Differences between the 
MOD and the FDD computer environments and 
system administration approaches became evi- 
dent. For instance, the FDD used network user 
accounts, with which TPOCC was not compati- 
ble. Other problems developed when the MOD 
moved to new releases of the HP operating sys- 
tem and Motif before these versions were avail- 
able to the FDD. In retrospect, the memoranda 
of understanding between the FDD and the 
MOD, which only addressed XTE AGSS release 
dates, should have also specified TPOCC ver- 
sion delivery dates, versions of system and sup- 
port software to be used, and all applicable 
standards. 

Increasing personal interaction and emphasiz- 
ing skill mix helped alleviate problems. After 
the FDD tested the releases in-house, the plan 
called for delivering them to the MOD for inte- 
gration into the operational environment. 
Because of all the unexpected problems 
encountered thus far in the project, the FDD 
development team decided to work with the 


MOD developers informally to integrate the 
system before formal delivery. The main prob- 
lems found during informal integration and test- 
ing were with installation instructions, not with 
the software itself. 

A final factor very important to the success of 
the XTE AGSS was staffing. Once the true 
magnitude of the development effort was under- 
stood, project management committed highly 
experienced and motivated individuals to the 
team. They provided a good skill mix that 
included both software development and appli- 
cation domain knowledge and C and FORTRAN 
experience. In spite of the pressures, this 
commitment led to a very good team spirit and a 
successful product. 


Lessons Learned 

The complexity of open systems was much 
deeper than anticipated in all three case study 
projects. The developers learned that ‘industry 
standards” are often evolving or competing con- 
ventions, that COTS products are marketed 
before they are mature, and that interoperability 
does not always live up to advertised expecta- 
tions. They discovered how much middleware it 
really takes to make a distributed system work. 
The organization realized how significant the 
choice of hardware is to the viability of the final 
system, how much hardware is needed to fully 
support a distributed development effort, and 
that the costs for support software and develop- 
ment environments can rival or exceed the cost 
of the hardware. They also had to find ways to 
overcome compartmentalization of open systems 
knowledge in their own and in interfacing organ- 
izations. We have grouped these lessons around 
organizational, technological, and managerial 
themes. 

Organizational Lessons 

Organizational transition plan. A planned 
transition for the entire organization, backed by 
management commitment, is needed. The case 
studies indicate that the FDD approached the 
transition on a project-by-project basis, not only 
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reducing coordination but also slowing the dis- 
persion of knowledge. Management did attempt 
to coordinate activities at the top levels of the 
organization, but the staff on the individual proj- 
ects received little information as to how their 
project fit into the plan. As a consequence, 
people focused almost exclusively on the chal- 
lenges of using the new technology on their own 
projects, with little incentive to share their expe- 
riences with others in the organization. 

Changing organizational roles. Changing tech- 
nology can blur traditional roles, garble com- 
munications, and cause friction. No doubt this is 
part of what makes transition plans hard to cre- 
ate in the first place. Effects of technology 
change can ripple across organizations in ways 
they cannot readily accommodate. The leaders 
of the organization must define and communicate 
a vision for doing business using the new tech- 
nology and help the staff make organizational 
changes stemming from it. Changing technology 
does not necessarily mean business reengineer- 
ing, but if the organization is making a major 
technology change it should carefully evaluate 
the impact on its business model as well. 

Outreach across organizational boundaries . 
Sharing experiences across project and depart- 
ment boundaries is critical during technology 
transition. ‘Department"' here means any por- 
tion of the organization that traditionally prac- 
tices ‘Information hiding"" from other portions. 
The case studies show that information barriers 
can exist even at the lowest levels. Groups of 5 
or 10 people down the hall from each other may 
not share information even though they are 
engaged in parallel transitions This may seem 
counterintuitive to anyone who has experienced 
the “office grapevine,"" but people do not grasp 
organizational plans through the grapevine. Per- 
sonal contact works well for transferring detailed 
knowledge when people have a focus and goals, 
but it takes a special effort to find that focus. 
Management must provide forums, whether 
formal or informal, for sharing new technology 
experiences in real time without ‘turf” issues 
interfering. 


Disseminating lessons learned. The FDD has a 
tradition of writing good history documents after 
each project to capture lessons learned, but often 
they come out too late to help the project plan- 
ners who really need them. Also, if a procedure 
for using them is not integral to the development 
methodology, the lessons may sit on the shelf 
unheeded. An organization should document 
lessons learned at points in the development 
process well before the project’s end and should 
make producing and using them part of the 
development procedure. The lessons should be 
disseminated in a way that will make them easy 
to access (for example, in a cross-indexed on-line 
library). The goal should be to coalesce the les- 
sons mto an institutional knowledge base. 

Technological Lessons 

Cultivating market awareness. The competitive 
marketplace drives the evolution of open tech- 
nologies, so using them effectively requires culti- 
vating and maintaining market awareness. An 
organization coming from a stable mainframe 
environment that does not emphasize compati- 
bility with the world beyond the vendor may be a 
“closed shop,” especially if that organization 
produces a very specialized product (such as 
space ground support systems). The case studies 
suggest that the FDD was not prepared to deal 
with rapid market evolution. In the past, the 
organization usually had time to choose tech- 
nologies carefully and experiment with ‘‘seed"" 
projects. This approach was not geared to the 
pace of change the developers had to adopt to 
accomplish the transition to open systems. The 
transition forced a cultivation of market aware- 
ness, which in turn requires applying the disci- 
pline and resources to track all aspects of 
industry evolution. Management must actively 
encourage technical staff to follow market trends 
and pursue continuing education. 

Training for front-line workers. Beware of 
unrealistic optimism on the part of both manag- 
ers and technical staff regarding the ease with 
which staff can master the new technologies. 
The case studies revealed that people had a ten- 
dency to think in terms of distinct skills to be 
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learned, new, but similar to existing skills. In 
reality, the mynad interrelationships of a new 
suite of technologies, and the industry context in 
which they are evolving, are very complex. Our 
experience was that the amount of ramp-up time 
needed to learn new technologies, from least to 
most, was for UNIX, C, networking, and 
X/Motif (most difficult to acquire even using a 
GUI builder). When most of the team has to 
learn all the technologies together, the time 
invested is significant. 

Technical compatibility. When a software 
development shop first adopts open systems 
technology, it may expect to easily interface with 
open systems in client and peer organizations. 
This expectation was not realized in the case 
study projects; U plug and play” is not yet the 
norm. Incompatibilities result if the organization 
does not have detailed knowledge of the tech- 
nologies used by the interfacing organization. 
Open systems invite cooperation but do not 
guarantee compatibility. Interacting organiza- 
tions should discuss and document their agree- 
ments on issues such as standards, COTS 
product versions, and configuration management 
assumptions. 

Retooling the infrastructure. Organizations 
such as the FDD with long-standing stable com- 
puting environments have usually developed 
customized software development toolsets and a 
supporting infrastructure. When moving to a 
new technology, problems that were previously 
solved in the legacy environment may need to be 
solved again because the infrastructure and tools 
have changed. Even a technically mature organ- 
ization may be unprepared for the extent to 
which it must develop new approaches to basic 
software engineering problems that it thought it 
had solved long ago. A mature organization may 
be at a disadvantage because of a high comfort 
level with its proven techniques. 

System engineering . In all three cases studied, 
the transition to open systems caused the 
developers to shift from a purely software engi- 
neering viewpoint to more of a system 
engineering perspective. In the absence of a 


stable technical infrastructure, the developers 
had to devote considerable time and effort to 
understanding engineering topics for which their 
previous project experiences had not prepared 
them. Both hardware and software components 
had to be treated more or less equally. Emphasis 
shifted from crafting systems from lines of code 
to selecting and integrating the right combination 
of hardware and software components. When no 
established computing infrastructure exists, 
developers must perform systems engineering 
analysis at the start of the project to plan for and 
procure sufficient resources. 

Project Management Lessons 

Realistic expectations . Project managers cannot 
expect to achieve all the goals during a technol- 
ogy* transition that the organization achieved in 
the stable technology. Aiming for these goals 
can lead to over-commitments and compromise 
the success of the transition. The project man- 
ager must be strategically aggressive but tacti- 
cally conservative, and careful when making 
commitments. 

Accurate effort estimation. Technology transi- 
tion requires investment. The SEL Manager ' s 
Handbook , source of the FDD’s project estimate 
models, recommends applying an additional 
effort multiplier of 2.3 when a project type and 
the technical environment are new to the organi- 
zation. Had the case study projects followed this 
guidance, the UIX and XTE AGSS projects 
would have started with much more realistic 
effort estimates. The GSS project, which did not 
involve the same degree of transition as the other 
two, came closer to the standard model, and the 
effort multiplier may not have applied to it. 

Staffing and skill mix. The manager in the leg- 
acy environment faces a particularly difficult 
staffing and training issue. The case study proj- 
ects used ‘hot” technology, but because the 
FDD’s existing technology was mainframe 
based, it did not tend to attract and retain people 
with expertise in new technologies. Those 
recruits who did have open systems experience 
generally were not experienced in either 
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application development or in the FDD’s legacy 
systems and problem domain. 

Training for technical managers. One problem 
with this technology transition was that the 
technical managers and senior technical people 
were reared in an older technology. The case 
studies show a tacit assumption that project 
managers would somehow “pick up” the open 
systems concepts sufficiently to competently 
plan and manage these projects. In fact, when 
project planners lack an understanding of the 
technology' their team is using, they may not 
understand the real issues and cannot make good 
planning decisions. Open systems approaches 
bring significantly different problem-solving 
tools and techniques. Technical managers need 
training and hands-on experience. They need to 
know what they are up against when setting 
schedules and budgets. 

Role of prototyping. Although useful for 
avoiding disaster, prototyping is not in itself a 
sufficient basis for project planning. A proto- 
type does not confer organizational learning. 
Even a second-time use of a technology may not 
uncover all the possible pitfalls. Organizations 
have to assimilate information until they reach 
the point of “intuition.” 

Methodology. Methodology requirements ori- 
ented toward the routine design problem may 
actually impede learning, because they assume 
the problem-solving technology is already well 
understood. For example, the requirement that 
all unit designs be completed before any units are 
coded makes it impossible to feed lessons learned 
about the new environment into the design proc- 
ess. Although progress is harder to measure, 
iteration promotes learning the new environment. 
When introducing new technologies, a more 
appropriate approach may be to develop the 
system framework first and the application func- 
tionality later. The project can then be broken 
into numerous small builds and progress and 
expended effort assessed after each build. The 
development plan should be readjusted accord- 
ingly. To gam integration experience m the new 
environment, functionality’ should be slipped 


from early to later builds rather than delaying 
delivery of early builds. 

Software metrics . Metrics are critical to under- 
standing the new technology. However, meas- 
urement programs established for the old 
technology may not be adequate for the new' 
Predictors based on source lines of code may not 
be meaningful when using GUI builders, code 
generators, and COTS packages. 


Conclusions and 
Recommendations 

A technology transition plan. While it is not our 
purpose to develop a model for technology 
transition planning, our observations do suggest 
issues that a transition plan should address 
Table 2 presents our suggestions from the per- 
spective of a fairly large organization with a 
mature and stable, but dated, technology infra- 
structure. (The ordering of topics does not imply 
a procedural sequence.) 

Climbing the hills of technology infusion. 
Adopting a new technology is like climbing a hill 
representing the cost of the transition. Few' 
computing professionals and managers are 
expert at estimating the height of the hill and the 
rate of progress over it. Yet as Figure 3 shows, 
the increasing pace of change bangs whole 
ranges of hills to climb. The FDD, having suc- 
cessfully applied the SEL process improvement 
concepts in a stable environment, was unpre- 
pared for the rapid pace of the transition to open 
systems. Perhaps the FDD, with its stable envi- 
ronment and funding, had become accustomed to 
investigating technologies at its own pace. In the 
current technological environment, however, we 
may not have the luxury to control which tech- 
nology' hills we will climb or when. 

Can we learn to adopt technologies faster and 
more efficiently? A common element in these 
case studies is a failure to realize that technology 
transition alters the essence of the design prob- 
lem. The literature on the design process distin- 
guishes between routine design and variant , or 
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innovative, design. In routine design, both the 
problem domain and the problem-solving process 
are well understood, and the main issue is 
accommodating an established solution to proj- 
ect-specific needs. But in variant design, while 
the problem domain may still be well understood, 
the problem-solving process is not. Approa ching 
the variant design problem as if it were just a 
more difficult instance of the routine problem, to 
which slightly adjusted models and procedures 
can be applied, leads to problems. 


Improving management models for “emerging 
technology” projects. Variant design problems 
can be expected whenever new technologies are 
adopted. The software industry needs to sys- 
tematize its knowledge of them. Project 
planners must understand when the organization 
is going through a transition that fundamentally 
changes the problem-solving process so they can 
approach it the right way. Of course, the 
problem is compounded by the feet that technol- 
ogy drives organizational structures; as industry 


Table 2. Recommended Content of Transition Plan 

Topic 

Comments 

Vision 

What is the purpose of adopting the new technology? Will it support and improve the organiza- 
tion’s business position? Examine assumptions regarding these issues to reveal aspects of the 
transition that others 

Industry 

assessment 

How mature is the technology? Look at the hardware/software solutions being adopted by other 
organizations. Attend trade shows and conferences. Challenge the assumption that your organi- 
zation is unique in its needs or functions. Be proactive in defining business direction in terms of 
new technologies. 

(^ganizatiotial 

assessment 

Consi<te : the impact : of technology on the whole organization; not just your department How 
will the tedmoiogy change the roles of supporting organizations? How will the organization 
operate after adopting the technology? 

Hardware/ 
software tradeoffs 

Challenge the assumption that existing equipment must be retained for cost-effectiveness. The 
cost of software development and development environments may outweigh equipment cost. 

Standards, 

conventions 

Make sure all the required standards are identified and followed. Understand fire HifWnw 
between established standards and industry conventions. 

Pilot projects 

Define realistic goals for pilot projects; avoid developing products best left to industry (such as 
distributed operating systems). Concentrate on using new technology to bolster the organiza- 
tion’s traditional strengths. Keep initial transition projects small. 

Staffing 

Staff transition tasks carefully. Exp mofiv atetL, capable people are essential to the 

transition project. Articulate die special skill needs tt> management* back the request with 
evidence, and be aggressive about resolving staffing problems and retaining team members. 

Personal contact 

Expedite personal contact across department boundaries. Establish mechanisms such as cross- 
department working groups, but avoid too much structure. Allow teams flexibility to discover 
what areas need focus and how to work together. 

Trainingplan 

Ensure that training is avail able; git on the side of too much. Project planners need exposure to 
the new technology at the time of planmng; developers need it when assigned to the project. 
Support staff also need training. 

Methodology 

An iterative approach promotes learning. Use numerous small builds to gain integration experi- 
ence in the new environment. Slip functionality rather than delay delivery. Challenge 
methodology requirements focused on the routine design problem. 

Metrics 

The new technology may demand different natrics™ 8 gn problem 
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A Where are we on Infusion Hill? 

T Where are we going and when will we get there? 



time 




Figure 3. The Hills of Technology Infusion 


retools, organizations discover possibilities that 
prompt them to reexamine their missions. 
Although this exploration can be guided only in 
broad outline, the need to steer projects through 
these uncharted waters remains. 

New Directions for the FDD 

Despite transition problems, the software devel- 
oped by the projects we studied appears to be of 
good technical quality. The XTE systems were 
proved reliable in testing and are being reused by 
other projects for upcoming missions. New proj- 
ects are using the UIX and the GSS in their 
designs. The FDD itself is embarking on full- 
scale conversion to a distributed system, porting 
or replacing up to 6 million lines of legacy soft- 
ware. A stable infrastructure for open systems is 
beginning to evolve within the FDD, improving 
prospects for success. 

Moving a large organization from a mainframe 
legacy to a new environment of open systems is a 
complex technology transition problem. The 
transition involves much more than a simple 
switch of tools and techniques. Transitions that 
cause sudden shifts from routine to variant 
design problems are likely to become more 
common in the future. Our challenge is to apply 
organizational learning techniques in staying 


abreast of industry developments, and to effec- 
tively incorporate them in our experience base. 
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Purpose and Method 


□ Problem: Transition to a new technology requires investment 
before benefits are realized — how can we plan and manage 
efficient transitions in the midst of rapid industry evolution? 

□ Method: Study three projects in the GSFC Flight Dynamics 
Division (FDD) moving from a mainframe environment to 
"open systems" workstation technology 

□ Goal: Improve our understanding of technology transition 
and identify lessons learned 
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Background: The FDD Software 
Development Organization 


□ Through the SEL process, the FDD has achieved a track 
record of continuous improvement in reuse, error rates, 
and other software characteristics 

□ Stable development environment: IBM mainframe with 
FORTRAN, and DEC VAX with Ada 

□ Focused SEL experiments: 00, Ada, Cleanroom, IV&V, 
resources usage 

□ Computing environment held relatively constant while 
process and products evolved 
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Background: Transition of the FDD to 
Open Systems 

□ FDD/SEL achievements were within the context of 
stable mainframe and VAX computing environments 

□ Now FDD is moving toward open systems 

• Workstation computing platforms, industry 
standards, and conventions 

• Use widely available COTS products; emphasize 
portability and interoperability 

• Goals are economic and technical: less vendor 
dominance, more competing solutions, "more 
bang for the buck" 

□ How will this dramatic change in computing 
environment affect our products and processes? 
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Background: Transition of the FDD to 
Open Systems 



The Case Study Projects 


mum 




UIX 

PC (SCO UNIX), HP 

65,000 C 

Multiapplication user 
interface system 

GSS 

DEC Alpha, HP 

212,000 Ada 

Multiapplication attitude 
support components 


HP 

150,000 C 
and FORTRAN 

Mission attitude ground 
support applications 


Planned using SEL models based on local mainframe and VAX experience 
with adjustments for new technology 
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Case Study Projects: Comparision of 

Results 




Compare to si» growth in 20% to 40% range and schedule growth In 5% to 35% range 
on recent maintenance and VAX development projects 
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Case Study 1 — UIX 


□ We wanted to develop a common user interface and 
executive framework for interactive, distributed mission 
support systems 

□ We did the logical thing: up-front prototyping 

• Led to necessary architectural and conceptual changes 

• Not a good basis for project planning: final system is 
much larger and more complex than prototype indicated 

□ Lack of a preestablished system architecure ("middleware") 
proved to be a significant technical and organizational 
stumbling block 


□ The project was refocused on the user interface and 
extended: wait for industry middleware to evolve before 
attacking distributed executive 
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Case Study 2 — GSS 


□ We wanted a class library of flight dynamics capabilities 
from which we could build our systems; we prototyped it 
along with the UIX 

□ We wanted to transition Ada development to workstation 
environment, but have not been able to except for 
integration and test phases 

□ We discovered that matching development toolset 
capabilities available on DEC/Alpha/Open VMS is not yet 
cost effective on our target platforms 

□ Current plan is to phase in development tools as market 
forces drive the costs of Ada development systems down 
(this is already happening) 
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Case Study 3 — XTE AGSS 

□ We needed to integrate with client/server software developed by 
another group at GSFC, and to provide our first interactive X/Motif 
system for mission support (UIX was not ready) 

□ We assumed we could achieve our current norms: compressed 
development schedules and reusable software 

□ We severely underestimated the complexity and functionality 
required to meet these goals in a new environment 

□ We underestimated the difficulties of interfacing with other group's 
software (same "open" technologies, but environment differences 
such as COTS products at different version levels) 

□ Technology transfer facilitated by relocating developers to the 
other organization's site to infuse their technology, and by 
adopting highly iterative implementation approach 

wr 
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Lessons Learned: Organizational 


□ A coordinated organizational transition plan, with 
management commitment, is essential 

□ Changing technology can blur traditional roles, 
garble communications, and cause friction, 
because the "old ways" do not always adapt well to 
new technology 

□ The organization must find ways to cooperate and 
share lessons learned across departmental 
boundaries; technology transition is not the time 
for information hiding! 


r'r'f" 


Lessons Learned: Technological 


□ Open systems and rapid industry change demand 
we cultivate market awareness to replace our 
"closed shop" outlook 

□ Open systems invite cooperation but do not 
ensure compatibility: stress coordination and 
communication 

□ Early training is important for both the technical 
managers and the frontline workers 

□ Problems previously solved in legacy environment 
(e.g., CM, reuse) often must be solved again in the 
new environment 
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Lessons Learned: Project Management 


□ Open systems require open minds: awareness of market 
trends, continuous organizational learning, structured 
feedback of lessons learned 

□ Use prototyping to avoid disaster but not as a basis for 
project planning 

□ Don't expect to achieve the goals of a technologically mature 
organization while you are transitioning 

□ We need a better management model for "emerging 
technology" projects 
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Conclusions and Recommendations 

□ We need scientific data about technology transitions: The 
industry needs to honestly appraise successes and failures 
and learn from them 

□ Our existing SEL models are not adequate for technology 
transitions: Upgrade them 

□ Open systems concepts and decreasing hardware costs 
force a systems (not just software) engineering approach 

□ Personal contact is the most effective means of information 
sharing on technology transition - need an institutional 
mechanism 

□ We must plan for continuously infusing technology and 
commit resources to that end 


SEW Proceedings 


209 


SEL-94-006 



The Hills of Technology Infusion 

□ In a rapidly evolving industry and an open marketplace, we 
must learn better skills for evaluating and adopting new 
technologies 



time 

Where are we on Infusion Hill? 

Where are we going and when will we get there? 



New Directions for the FDD 

□ XTE AGSS subsystems are being reused for upcoming 
missions 

□ EOSTGSS project just completed PDR 

• Up-front emphasis on system engineering 

• Using UIX as part of infrastructure 

□ Flight Dynamics Distributed System 

• Port or replace the 6 million SLOC of our mainframe 
and VAX legacy 

• Will use GSS and UIX 

• Infrastructure is now coming into place 
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